Corrige a compatibilidade entre Celery e Redis na versão 2.7.0 - #160

O que esse PR faz?

Fixa Kombu 5.6.2 e declara o transporte Redis nas dependências do Celery/Kombu, mantendo Celery 5.3.6, redis-py 5.0.1 e a versão da aplicação 2.7.0.

Evita o erro de conexão causado pelo Kombu 5.7.0, que exige um redis-py mais recente. Acrescenta uma conexão real Celery–Redis ao CI.

Onde a revisão poderia começar?

requirements/base.txt e .github/workflows/ci.yml.

Como este poderia ser testado manualmente?

Construir a imagem de produção e validar conexão ao Redis, execução de tarefa por um worker e entrega de tarefa periódica pelo Beat, em ambiente isolado.

Verificação realizada com Redis 8.0.2: a imagem original reproduziu VersionMismatch; a corrigida passou no transporte, worker, tarefa periódica e pip check. Regressão: 376 testes aprovados, 2 ignorados; OpenAPI nos dois modos e Gitleaks aprovados.

Algum cenário de contexto que queira dar?

Correção limitada à compatibilidade do broker, sem atualização de Wagtail, migrações ou mudança funcional na API. Não altera a imagem já publicada nem executa implantação.

Screenshots

Não se aplica.

Quais são os tickets relevantes?

Relacionado à #158, no recorte de compatibilidade Redis/Celery. Não encerra a atualização mais ampla de dependências.

Referências

• Dependências Redis do Celery 5.3.6
• Dependências do Kombu 5.6.2

Segurança da informação (NSI.04)

Este PR manipula dados sensíveis ou pessoais (LGPD)?

• Sim — descreva os controles de proteção aplicados (criptografia, mascaramento, anonimização, etc.):
• Não

Este PR altera autenticação, autorização, controle de acesso ou gerenciamento de sessão?

• Sim — descreva o que mudou e por quê:
• Não

Este PR introduz, atualiza ou remove dependências de terceiros?

• Sim — fixa a dependência transitiva Kombu e declara os extras Redis. Validação funcional e pip check aprovados; SBOM/Trivy pendente.
  • Verificado e aprovado
  • Pendente / vulnerabilidade aceita com justificativa: verificação SBOM/Trivy ainda não executada; não se declara aceite de vulnerabilidade.
• Não

Este PR foi validado pelo pipeline de segurança (SonarQube / Trivy)?

• Sim — link do job:
• Não aplicável a este PR (justifique):

Pendente de validação pelo pipeline; Gitleaks local aprovado.

Este PR concatena, monta ou executa comandos SQL, HTML ou JavaScript a partir de entrada externa?

• Sim — confirme que há sanitização/parametrização (prepared statements, escaping, etc.):
• Não

Este PR expõe novos endpoints, telas ou serviços?

• Sim — HTTPS obrigatório está garantido e o acesso segue o princípio de menor privilégio?
• Não

Algum segredo, senha, chave ou token está sendo adicionado ao código-fonte?

• Não, nenhum segredo foi commitado
• Sim (bloquear merge e corrigir antes de prosseguir)